fix: VRAM and memory leaks in window, session, output, and multi-GPU paths - #2500

The cursor image_cache accumulated animation frames without bound as it grew
across shape changes. Track the last cursor icon and clear the cache when the
shape changes.

Developed with AI assistance (Claude Code); all changes have been reviewed and
are understood by the author.

…aces

pending_activations entries for Wayland surfaces that died before completing were
never removed and accumulated indefinitely. Drop them during Shell::refresh once
the surface is no longer alive.

Developed with AI assistance (Claude Code); all changes have been reviewed and
are understood by the author.

Removing an output left its LockSurface in SessionLock.surfaces, retaining the
surface's GPU buffer. Remove the output's entry when the output is torn down.

Developed with AI assistance (Claude Code); all changes have been reviewed and
are understood by the author.

The retain filter for ActivationKey::X11 always returned true, so entries for X11
windows that died before completing mapping accumulated indefinitely. Keep an X11
entry only while a matching pending window still exists.

Developed with AI assistance (Claude Code); all changes have been reviewed and
are understood by the author.

postprocess_textures kept the node's GlesTexture render buffers after a DRM node
was removed, leaking them on GPU hot-unplug. Drop the node's entry in
node_removed.

Developed with AI assistance (Claude Code); all changes have been reviewed and
are understood by the author.

OutputZoomState, stored in Output.user_data(), holds an IcedElement whose outputs
set contains the same Output, so the Output never drops after disconnect — leaking
it, its user_data, and the GPU textures held by the IcedElement. Call
output_leave() on the zoom element before removing the output to break the cycle.

Developed with AI assistance (Claude Code); all changes have been reviewed and
are understood by the author.

A multi-GPU client can be active on several render nodes. The disconnect handler
broke out of the device loop after the first node it freed, leaking the client's
id (and its imported buffers) on every other device it had used. Remove the client
from every device, then refresh used devices once if any were freed.

Developed with AI assistance (Claude Code); all changes have been reviewed and
are understood by the author.

Moves onto the revision carrying `Renderer::invalidate_caches` and the
multi-GPU cache methods the next commit calls into. The bump crosses three
API changes:

- The tablet protocol handling moved from `wayland::tablet_manager` to
  `input::tablet` and became event-struct based, with an explicit
  `TabletSeatHandler::ToolFocus` and per-frame `frame()` calls. Axis state
  is now sent as one `AxisFrame` built from the libinput event's
  changed-axis flags, which is what the previous sequence of individual
  setter calls expressed.
- `PointerConstraintRef::deactivate` takes the state, surface and pointer,
  because smithay now calls `PointerConstraintsHandler::remove_constraint`
  from it; the handler also receives the constraint being removed.
- `remove_constraint` therefore runs with the per-surface constraint mutex
  held and, on the pointer-leave path, from inside pointer dispatch.
  Applying the cursor position hint there deadlocks the compositor, since
  `apply_cursor_hint` retakes that mutex and drives `pointer.motion`, so
  the seat lookup and the warp are deferred to an idle callback. The hint
  is now honoured when the constraint is deactivated as well as when it is
  destroyed, which is what `zwp_locked_pointer.set_cursor_position_hint`
  specifies; clearing the hint on the first makes the second a no-op.

The lockfile also moves `drm-ffi` to 0.9.1 and `drm-sys` to 0.8.1, which the
new revision requires, and drops `rand` with it.

Developed with AI assistance (Claude Code); all changes have been reviewed and
are understood by the author.

The renderers owned by the main thread's `GpuManager` - used for output
(re-)configuration, screenshots and image-copy captures - draw only on
demand, and a renderer only flushes its GL destruction queue and only
re-imports its caches when it draws. A dead client's textures therefore
stay queued, and a live client's imports stay cached, until whatever
happens to draw next, which may be minutes or hours away. Both pin the
buffers in VRAM for that whole time. The per-output render threads have
no such problem: they draw every frame.

Tie the two halves of the cleanup to the events that create the garbage
rather than to a timer:

- Destruction schedules a drain. `buffer_destroyed` and
  `CompositorHandler::destroyed` set a flag that `refresh` acts on with
  `GpuManager::cleanup_texture_cache`, so the queued deletions are flushed
  on the next event-loop pass instead of at the next draw. Batching through
  the flag keeps a client exit that destroys hundreds of surfaces to one
  drain.
- Infrequent draws invalidate afterwards. Output (re-)configuration,
  screenshots and image-copy captures call `invalidate_caches` once they
  are done, since the imports they just cached provide no benefit before
  the next such draw and the next one re-imports what it needs.

Both go through the `GpuManager` cache methods rather than a hand-rolled
loop over `devices_mut`. Such a loop cannot reach the buffers cached for
copying between a render and a target node: those belong to the manager,
keyed by node pair, rather than to any one renderer. `offscreen_renderer`
builds exactly such a render-to-target renderer for screencopy and
screenshots, so a per-device loop left a full output-sized dmabuf per node
pair pinned in VRAM.

Captures drain rather than invalidate, because a screencast session
captures repeatedly and its imports are worth keeping between frames.
Screenshots on the Glow path do neither: the winit and X11 backends redraw
every frame, and the KMS software fallback holds no VRAM.

The per-output render threads get the same treatment for consistency, which
supersedes `f86cd933`: their end-of-draw loop over `devices_mut` predates the
manager-level methods and is what those methods were added to replace.

Developed with AI assistance (Claude Code); all changes have been reviewed and
are understood by the author.

Removing a connector dropped its `Surface` without joining the thread it
owns. A bare drop only signals the thread to end. If a later reconfigure
takes the DRM compositor write lock before the detached thread finishes
its in-flight frame, the thread blocks on the read lock, never observes
`End`, and so never releases its renderer, swapchain and postprocess
offscreens. That strands a full set of output-sized render targets in
VRAM for the rest of the session: compositor VRAM does not return to its
previous floor after a display is unplugged, and each subsequent unplug
adds another set.

Join the thread so those resources are released before the connector's
removal completes. Unlike `apply_config_for_outputs`, this path holds no
compositor lock, so the join cannot deadlock against the thread's own
read lock; the two other `drop_and_join` call sites rely on the same
property.

Developed with AI assistance (Claude Code); all changes have been reviewed and
are understood by the author.